「AmplifyとAppSyncでモダンでイケてるWebサービスを爆速で立ち上げようぜ 」を話しました #devio2020

「AmplifyとAppSyncでモダンでイケてるWebサービスを爆速で立ち上げようぜ 」を話しました #devio2020

クラスメソッドの年次技術イベント「Developers.IO 2020 CONNECT」で6月23日(火)に「AmplifyとAppSyncでモダンでイケてるWebサービスを爆速で立ち上げようぜ」というテーマで発表した資料を共有します。
Clock Icon2020.06.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、もこ@札幌オフィスです。

6月16日より、クラスメソッドの年次技術イベント「Developers.IO 2020 CONNECT」を開催しています。期間は2020年6月16日(火)から7月7日(火)、テーマごとに7日間の日程に分けて開催、セッションはなんと合計100本以上あります。

Developers.IO 2020 CONNECT

私は、6月23日(火)のライブセッションの3本目を担当しました。登壇の内容についてはこちらをご覧ください。

登壇動画

ライブセッションだけでなく多数の技術について動画を公開しています。下記のYouTubeチャンネルの登録もお願いします。

登壇資料

 

Q&A

Q1. Amplifyを使うことでインフラ側がブラックボックスになってしまい、セキュリティ上の不安や仕様考慮漏れによる不具合が怖いのですが、どうすればそういった不安を拭えますか?

確かに脆弱性や不具合がある可能性は無きにしも非ずですが、自前で全てを実装するとしても、脆弱性や不具合が0になるとは断言出来ませんし、脆弱性、不具合が発覚したときは自前で解決する必要があります。

SaaS系のサービスの場合、責任分界点が明確となっているため、仮にプラットフォームに脆弱性や不具合があったとしても自前で対応する必要が無いのがメリットと言えると思います。

Q2. Amplifyで作成したソースコードを、検証や本番にデプロイする際にはどのような形で行うのが良いですか?(バックエンド系) バックエンドのデプロイはCFやServerless FWと連携できる?

CloudFormationやCDKを書くことで柔軟に対応することが可能です。

AWS Startupブログの「スタートアップが AWS Amplify を使うべき3つの理由」という記事の中でも紹介されていますので、合わせてご確認ください。

Q3. AmplifyからもAppSyncのpipeline resolverが使えますか? (無数にある)ユーザーグループ毎にデータに対する権限制御を行う場合はpipeline resolverが必要になってくると思っていますが、現状のAmplifyの機能でも出来るのか知りたい。

Amplify CLIのIssue、Pipeline resolver field-level authorization #4262にて議論されていましたので、ご確認ください。

Q4. Amplifyは発展中の技術だと思いますが、現在のレベルでどの様な用途のアプリまでだと利用可能な状況でしょうか? もしもわかれば、今後の進化のスピード感(本格的なアプリで使っても問題ないんじゃないかと思われるレベル)になるまでどの程度かかりそうか知りたい。

Amplifyのコミュニティーは活発ですし、進化のスピードという点ではとても早いと思います。他のサービスとの連携で「かゆい所に手が届かない」ような状態になったとしても、従来通りのAPI Gateway/Lambdaのような構成を取ることも出来るため、柔軟に対応出来ると想います。

Q5. Amplify魅力的ですね。 本日の本質とは外れますが、これまでOGPが課題でSPAを採用できませんでした。ページごとに動的にOGPを変更できないためです。Amplifyで解決することができたりしますでしょうか。(FirebaseだとFunctionsを使って対応できるらしいのですが、AWS使いたかったのでその時はあきらめました)

Lambda@Edgeを利用して実装しようと思えば出来るかと思いますが、複雑になってつらくなって来ると思いますし、SSRしたいですよね...

現時点でSSRを行うことは出来ませんが、"具体的なスケジュールはありませんが、積極的に検討しています。" とコメントされていますので、今後に期待です!

https://github.com/aws-amplify/amplify-js/issues/1613#issuecomment-609053106

Q6. Amplifyでバックエンドをデプロイすると、リソース名にランダムな名称が入ってるくと思うのですが、AWSの他のサービスと連携するときには、逐次調べて対応することになりますか?バックエンドのリソース名を指定した名前にしたり、自動でリソース名を取得する様なやり方があるのでしょうか?

連携するAWSサービスをCloudFormationで作成する場合、AmplifyのCloudFormationで作成されるリソースをOutputs部分で出力した上で、ImportValueでARNを回収することが可能です。(質問の意図が汲み取れていなかったらすみません)

Q7. Amplify+Appsyncに向いてること、向いてないことというのがあれば、教えてください。

スモールスタートが出来る点が最大かつ最強のメリットですが、SPAを前提としているような技術のため、React, Vue, Angularなどを導入していないプロジェクトなどでは移行することが難しいと思います。

Q8. Amplifyを知る前だと、何のプラットフォーム環境が一番好みでしたか?そこからAmplfy使用へ切り替えで気になった点がありますか。

私の場合は、前職でECSを使っていたため、ECS/Fargateなどが好きだったりします。

気になる点としては、React, Vue, Angularのフロントエンドの言語、ライブラリーが主役となる技術のため、これまで導入したことのない組織やチームがReactやVue等を使っていく場合、学習コストが掛かる可能性がある、という点です。

Q9. スライドでblogテーブルやproblemテーブルなど分けて実装してましたが、DynamoDBのようなNoSQLはリレーショナルなテーブル構成はNGかと思います。Amplifyを使うことによりRDB的実装をしていいのでしょうか?

スライドでご紹介しているスキーマ設計に関してはあくまで一例であることをご了承ください。

AppSync ドキュメントの 「高度な機能 - リレーションとページ分割」部分にて、TodoとCommentの二つのデータを保持する例が解説されていましたので、合わせてご参照下さい。

Q10. Amplifyの想定ユーザははどのような属性のユーザでしょうか? フロントエンジニアが触るにはDynamoDBのテーブル設計手法を知っておかなければ難しいと感じましたし、サーバサイドエンジニアが触るにはフロントエンド技術がネックになってくると思いました。

Amplifyは提供されているライブラリーがフロントエンドのライブラリー(React, Vue, Angular等)となっているため、メインの対象としてはフロントエンドエンジニアとなるかと思います。

Q11. 今後のAmplifyに期待しているのですが、Amplifyの最新情報をウォッチするにはどの辺りのサイトを見ているのがいいのでしょうか?

AmplifyのGitHubのIssueやPull Request、AWSの公式ブログを見て頂くと、最新の一時ソースが見られて良いかと思います!

https://github.com/aws-amplify/amplify-js

https://github.com/aws-amplify/amplify-cli/

https://github.com/aws-amplify/amplify-console

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.